Content management systems provide many services for the management of digital content. The basic client functions are logon, logoff; create folder, item or part; index item or part; search indexes; retrieve folders, item or parts; store parts; replace parts; and delete parts. In addition, a plurality of other features could be provided such as encryption, system administration, streaming of audio and video, caching functions or other types of management functions.
Content Management System Block Diagram
FIG. 1 illustrates the basic data flow in a content management system 100. The system includes a client 102, library server 101 and a plurality of object servers 103a–103c. The client 102 comprises an application and a toolkit. The toolkit includes a daemon process 106 that sends and receives data on behalf of the client. The client makes requests to the library server 101 and receives results. Objects are transported between a plurality of object servers 103a–103c and a plurality of the daemon process of the client as directed by the library server 101.
A given object is defined by an entry in the index or list of objects by a unique identifier and coupled with searchable attributes including the file or object server identifier and a collection identifier. The collection identifier describes how the object is to be managed for storage. A collection is a unit of storage conceptually a cabinet where objects are placed. It may consist of many volumes of various storage media and a set of rules as to how the actual objects are stored and handled. The library server 101 and each of the plurality of object servers 103a–103c are utilized in the conventional content management system 100 to manage digital content. Their functions are described below.
For a further description of the basic functions of the library server 101 and one of the plurality of object servers 103, refer now to the following discussion in conjunction with the accompanying figures.
Library Server 101
FIG. 2 is a diagram that illustrates the various elements of a conventional library server 101. The library server 101 holds index, attribute and content information in a searchable form within a relational database or through auxiliary servers. In a preferred embodiment, the library server 101 contains a foldering system and references to data objects that may be stored on an object server or other external file systems. The data objects may be any type of digitized information. The library server 101 also typically contains a workflow system.
As is seen, the conventional library server comprises a command monitor 120, a jobber 122, a plurality of child processes 124a–124e, and a database 126. The function of each of these elements will be described hereunder.
Command Monitor 120
The command monitor 120 is the main line for server code. The command monitor 120 also provides server control logic and starts other processes.
Jobber 122
The jobber 122 builds static access modules for the database to improve query performance.
Child Processes 124a–124e 
The child processes 124a–124e perform requests from the clients (over the network, for example). The requests include but are not limited to query, add, update, attribute data, passes on store, retrieve, replace requests for objects to object server. The number of child process is configurable.
Database 126
The database 126 stores attribute and server control information. The database 126 of the library server 103 is accessed as needed by the child processes.
The library server 101 also includes a plurality of tables. The tables include a part table, object server table, and a collname table.
Parts Table 127
The function of the parts table 127 is described hereinbelow. One row of the table exists for each part. Parts are stored on object servers. The row identifies the item part and maps its location to an object server collection.
Object Server Table 129
The object server table 129 maintains information concerning the plurality of object servers.
Collname Table 131
The collname table 131 maintains the names of each collection for each object server.
Object Servers 103a–103c 
Each of the object servers 103a–103c holds objects as files or references to other storage systems. The object server provides for name translation from library server name to file system name/location and for hierarchical storage management and transport of objects. Each of the object servers 103a–103c in a preferred embodiment also stores meta information in a relational database and in transaction log files. Finally, each of the object servers 103a–103c in a preferred embodiment also stores objects in files or other storage subsystems.
FIG. 3 is a diagram, which illustrates the various elements of a conventional object server 103. As is seen, the conventional object server comprises a command monitor 105, a purger 107, a destager 109, a migrator 111, child processes 112a–112e, a staging area 114, a plurality of volumes 116, and a database 118. The functions of these elements are described below.
Command Monitor 105
The command monitor 105 is a main line for server code, provides server control logic and starts other processes.
Purger 107
The purger 107 cleans the cache and removes least recently used items.
Destager 109
The destager 109 moves objects from cache to first storage class. The destager 109 maps a storage class to one or more volumes or to another object server. In the destager 109 mapping information is encoded in the database.
Migrator 111
The migrator 111 is an object server process that implements the storage manager activity moving objects from initial permanent storage to subsequent storage. The migrator 111 moves objects from one storage class to another storage class. Movement is defined by time and sequence as part of a management class.
Child Processes 112a–112e 
The child processes 112a–112e perform the requests passed from the library server 103 to the client 102 daemon processes (over the network). The child processes 112a–112e store, retrieve, and replace requests for objects to object server. The number of child processes 112a–112e is configurable.
Staging Area 114
The staging area 114 is a cache area for object storage.
Volumes 116a–116d 
Volumes 116a–116d are permanent storage media. The volumes 116a–116d may be disk, tape, optical or any type of storage subsystem.
Database 118
The database 118 holds object location and name mapping, and the system managed storage information and replication work requests and server configuration information.
A feature within the object server 163 is an object server table 121. The function of the object server table 121 is described below.
Object Server Table 121
The object server table 121 provides the objects that are stored and managed by that object server. One row within the table exists for each object stored and managed by the object server. The row identifies the object and maps its identifier to a local filename.
Functional Description
The function of the conventional content management system 100 (FIG. 1) is typically transactional in nature. A typical process for a transaction in a content management system is an object store process. In an object store process objects are stored in the appropriate locations within the system. FIGS. 4–6 are diagrams that illustrate conventional process for storing an object in a content management system.
First, in a begin transaction (FIG. 4), the client calls the application programming interface to store a part, via step 402. A memory pointer is then passed to the daemon within the client for use when an object server requests the part, via step 404. The store request contains the item and part information.
FIG. 5 illustrates a retrieve process. After receiving the store request from the client, the library server validates the store request and determines the destination information for this part, via step 502. The library server also inserts a row into the parts table. The library server then sends the store request to the selected object server, via step 504. This store request contains the part name, collection name, object size, daemon address and port, and time information.
After the object server receives the store request, the selected object server validates the store request and determines a storage location for the part, via step 506 (possibly a cache). The object server reserves file space for the object. The object server also logs the file location and cleans up resources. The object server then requests from the client a daemon to allow for sending the object, via step 508.
After receiving the request, the client daemon validates the object request and matches the object request to information passed from the client, via step 510. Then the daemon sends a response with the object appended thereto to the object server, via step 512. The object server places the object in prepared file space. Then the object server inserts a row into the object table. Finally, the object server sends a store response to the library server, via step 514. The library server then checks the response and sends a store response to the client, via step 516.
Thereafter the end transaction process is initiated as illustrated by FIG. 6. In the end transaction process the client receives the store response from the library server, via step 602. Then, the client sends an end transaction commit request to the library server, via step 604. The library server then sends an end transaction commit request to each object server contacted in this unit of work, via step 606.
Then, each of the object servers contacted adds a commit record to its respective transaction log and commits the database changes, via step 608. Each of the object servers then sends an end transaction response to the library server, via step 610. Each of the object servers processes their transaction logs.
After the library server receives the end transaction response from each of the object servers, the library server checks for any response errors, and sends an end transaction response to the client, via step 612. The transaction is now completed and the client inspects the results, via step 614.
Although this typical process is utilized extensively to manage data, it is oftentimes desired that multiple replicas of an object or different object servers be resident within the system. Replication provides for reliability in a variety of ways. For example, it can be utilized as part of a comprehensive data security model to provide offsite storage. In addition, replicated parts lost due to a hardware, software or administrative error can be recovered by a utility if a copy exists. It also provides for availability of objects. For business, legal or regulatory reasons (depending on locale) objects (possibly legal documents) may be required to reside on certain classes of media, such as optical.
The performance characteristics of this media may conflict with the desired access rate for a given customer. Replication to a faster media can enable keeping a copy on the legal storage medium and a copy on fast access medium over a longer defined period than normal caching practices permit. Replication also provides backup redundancy, the ability to maintain a copy at two or more sites. Higher availability of objects is also achieved via multiple peer copies.
However, in conventional content management systems replication systems have not been implemented. One way of replicating objects is to replicate an entire database in a plurality of object servers. This would greatly increase the complexity and could affect the performance of the content management system. Such a system would require significant “intelligence” in each of the object servers to identify which object server has copies such that one object server would have to be able to identify if another object server has the desired object therewithin.
Accordingly, what is needed is a system and method for object replication, which does not significantly affect the cost and efficiency of the content management system. The present invention addresses such a need.